Systems and methods for enhanced mesh networking

ABSTRACT

A method for enhanced mesh networking, preferably including performing network analysis, configuring router link parameters, and managing routing paths. A metric for routing path assessment, preferably including a throughput metric and a channel utilization metric. A Segment Table Announced Mesh Protocol, preferably including determining network segments and designating forwarding devices for communication between the network segments.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application Ser.No. 62/418,520, filed on 7 Nov. 2016, which is incorporated in itsentirety by this reference.

TECHNICAL FIELD

This invention relates generally to the computer networking field, andmore specifically to new and useful systems and methods for enhancedmesh networking.

BACKGROUND

The modern internet has revolutionized communications by enablingcomputing devices to transmit large amounts of data quickly overincredibly vast distances. The rate of innovation set by application andweb developers is breathtakingly fast, but unfortunately, not allaspects of the internet experience have kept pace. In particular, evenas people rely more and more heavily on home networking solutions toenable internet connectivity for a rapidly increasing collection ofelectronic devices, the technology underpinning those solutions oftenprovides a woefully inadequate user experience. In particular, manyusers find that a single wireless access point is not able to providewireless coverage for an entire home or small business. While technologyexists to extend the wireless network, it is often both difficult toconfigure and inefficient in performance. Thus, there is a need in thecomputer networking field to create new and useful systems and methodsfor enhanced mesh networking.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a diagram representation of a system of an inventionembodiment;

FIG. 2 is a diagram representation of a system of an inventionembodiment;

FIG. 3 is a schematic representation of a smart router of a system of aninvention embodiment;

FIG. 4 is a network chart representation of an example system of aninvention embodiment;

FIG. 5A is a network chart representation of the example system of theinvention embodiment;

FIGS. 5B-5C are network chart representations of path requests and pathreplies, respectively, sent within the example system of the inventionembodiment;

FIG. 5D is a network chart representation of a routing path in theexample system of the invention embodiment;

FIG. 6 is a chart representation of a method of an invention embodiment;

FIG. 7A is a network chart representation of an example network usingSTAMP; and

FIGS. 7B-7D are views of the network chart representation of FIG. 7A,depicting wireless segments, Ethernet segments, and potential forwardingdevices, respectively.

DESCRIPTION OF THE INVENTION EMBODIMENTS

The following description of the invention embodiments of the inventionis not intended to limit the invention to these invention embodiments,but rather to enable any person skilled in the art to make and use thisinvention.

1. System for Enhanced Mesh Networking

A system 100 for enhanced mesh networking includes a plurality of meshnetwork capable routers 110, as shown in FIG. 1. The system 100 mayadditionally or alternatively include a router management platform 120and/or a management application 130.

The system 100 functions to enable seamless wireless coverage of an area(e.g., a user's home) using mesh networking while reducing thecomplexity of configuring such a network. Typically, to configure aninternet-connected wireless mesh network, a user must configure a firstrouter to serve as a gateway to the internet (e.g., by connecting therouter to a cable modem). Further, some networking device (generally theaforementioned first router) must also be configured to serve as anetwork address translation (NAT) server, a dynamic host configurationprotocol (DHCP) server, and a wireless access point. Then, to extendwireless coverage as shown in FIG. 2, additional devices (e.g., wirelessrouters, access points, repeaters) must be added. Even in the simplecase of two or three wireless access points, the configuration optionsare virtually endless. For example, the access points could exist on asingle bridged network, or could be separated into different networks(e.g., could be assigned to different VLANs; that is, virtual local areanetworks). The access points could be connected to each other byEthernet cables, or simply serve as wireless repeaters. The accesspoints could share available Wi-Fi channel space in any number of ways.

Even for experienced users, the array of network configurationsavailable can be extremely overwhelming. The system 100 preferablyperforms much of this configuration both automatically anddynamically-optimizing the network for a user's needs without requiringextensive computer networking knowledge or hassle.

The mesh-network capable routers 110 are preferably multi-band (e.g.,dual-band, tri-band, etc.) routers substantially similar to thosedescribed in U.S. patent application Ser. No. 15/008,251, the entiretyof which is incorporated by this reference. Additionally oralternatively, the routers 110 may be any suitable networking devices(e.g., smart access points).

The routers 110 preferably include a Wi-Fi radio and a processor. Therouters 110 can additionally or alternatively include a Bluetooth radio,an Ethernet interface, and/or any other suitable hardware or software.In one example implementation, as shown in FIG. 3, a smart routerincludes two Wi-Fi radios: one 5 GHz radio and one 2.4 GHz radio, aBluetooth radio capable of Bluetooth Smart communication, anauto-sensing gigabit Ethernet interface, an ARM processor, DDR RAM, EMMCstorage (for router firmware), and a USB interface (e.g., for addingnetwork-accessible storage). In a second example implementation, a smartrouter includes three Wi-Fi radios: two 5 GHz radios and one 2.4 GHzradio, a Bluetooth radio capable of Bluetooth Smart communication, an802.15.4 radio (e.g., configured to communicate using one or more802.15.4 protocols, such as Thread, ZigBee, etc.), an auto-sensinggigabit Ethernet interface, an ARM processor, DDR RAM, and EMMC storage(for router firmware). In a third example implementation, a smart routerincludes two Wi-Fi radios: one 5 GHz radio and one 2.4 GHz radio, aBluetooth radio capable of Bluetooth Smart communication, an 802.15.4radio (e.g., configured to communicate using one or more 802.15.4protocols, such as Thread, ZigBee, etc.), an ARM processor, DDR RAM, andEMMC storage (for router firmware). Alternatively, the smart routers canbe any suitable router, wireless access point, and/or other networkingdevice. However, the smart routers can include any suitable combinationof any suitable radios (e.g., short-range radios such as NFC, RF, etc.),processing systems, sensor set, or other components.

The Wi-Fi radio(s) preferably function to provide wireless access to therouter 110. The Wi-Fi radio preferably serves to allow electronicdevices (e.g., smartphones, laptops, gaming consoles) to communicatewirelessly with the router 110 and with each other through a LAN, aswell as to allow routers 110 to communicate with each other over a mesh.

Each Wi-Fi radio preferably includes at least one antenna; additionallyor alternatively, the Wi-Fi radio may include an interface to connect toan external antenna. Antennas may be of a variety of antenna types; forexample, patch antennas (including rectangular and planar inverted F),reflector antennas, wire antennas (including dipole antennas), bow-tieantennas, aperture antennas, loop-inductor antennas, ceramic chipantennas, antenna arrays, and fractal antennas. The Wi-Fi radiopreferably supports communication over all of IEEE 802.11 a/b/g/n/acstandards (as well as the modified 802.11 s standard discussed later),but may additionally or alternatively support communication according toany standard (or no standard at all).

The router 110 may include any number of Wi-Fi radios operating on anysuitable frequency ranges. In one implementation, the router includestwo or more Wi-Fi radios: one or more operable on the 2.4 GHz band andanother one or more operable on one or more 5 GHz bands (e.g., 5.2 GHzband, 5.8 GHz band, 5 GHz bands requiring use of DFS, etc.). The router110 may additionally include a switchable radio, enabling the router 110to select from two different communication modes (2.4 GHz+5 GHz or 5GHz+5 GHz) in order to maximize connection quality.

The Wi-Fi radios preferably operate using single-input/single-output(SISO) communication techniques, but may additionally or alternativelyoperate using multiple-input and/or multiple-output communicationtechniques (e.g., SIMO, MISO, MIMO). If the Wi-Fi radios operate usingMIMO techniques, the Wi-Fi radios may use any type of MIMO techniques(e.g., precoding, spatial multiplexing, space-division multiple access,and/or diversity coding). Further, the Wi-Fi radios may perform MIMOcommunication either independently (e.g., a radio performs MIMOcommunication with multiple antennas coupled to that radio) orcooperatively (e.g., two separate radios perform MIMO communicationtogether).

The Bluetooth radio functions to allow devices to communicate with therouter 110 over a connection mechanism alternative to Wi-Fi. TheBluetooth radio is preferably used to allow the router 110 to beconfigured for the first time by a smartphone (or otherBluetooth-enabled computing device). The Bluetooth radio mayadditionally or alternatively be used for any other purpose; forexample, for configuring the router 110 at a different time, forcommunication between routers 110, or for communication with smartdevices in a home (e.g., smart locks, light bulbs). The Bluetooth radiopreferably supports the Bluetooth 4.0 standard, including communicationscapabilities for classic Bluetooth as well as Bluetooth Low-Energy(BTLE). The Bluetooth radio preferably switches between classicBluetooth and Bluetooth Low-Energy, but may additionally oralternatively be capable of communicating over both simultaneously.

The Bluetooth radio preferably includes at least one antenna;additionally or alternatively, the Bluetooth radio may include aninterface to connect to an external antenna. Antennas may be of avariety of antenna types; for example, patch antennas (includingrectangular and planar inverted F), reflector antennas, wire antennas(including dipole antennas), bow-tie antennas, aperture antennas,loop-inductor antennas, ceramic chip antennas, antenna arrays, andfractal antennas.

The Ethernet interface functions to provide wired connectivity to therouter 110. The Ethernet interface preferably allows wired devices(including other routers 110) to connect to the router 110. The Ethernetinterface preferably includes a plurality of Ethernet ports. Ports ofthe Ethernet interface are preferably capable of 1000BASE-T (i.e.,gigabit) communication, but may additionally or alternatively be capableof communication at any rate. The Ethernet interface preferablyautomatically sets the communication rate based on the capabilities ofconnected devices, but may additionally or alternatively set thecommunication rate manually. In addition to the Ethernet interface, therouter 110 may additionally or alternatively perform wired communicationover any wired interface. For example, the router 110 may performcommunication through a powerline interface (e.g., Ethernet over Power).

The router 110 preferably includes a microprocessor and may additionallyor alternatively include any other hardware. For example, the router 110may include a USB interface (for connection of network-attached storage,a DLNA server, etc. or for configuration purposes). In one embodiment,the router 110 includes a hardware encryption module (HEM). The HEM ispreferably a chip that stores an encryption key securely (e.g., theAtmel SHA204) and performs data encryption based on that key, but mayadditionally or alternatively be any hardware module capable ofencrypting transmissions from and/or decrypting transmissions to therouter 110.

The router 110 preferably stores firmware and/or software on an embeddedMultiMediaCard (eMMC), but may additionally or alternatively storefirmware and/or software in any suitable storage solution.

The router 110 preferably operates as a Linux server running Pythonprograms, but may additionally or alternatively operate using anysoftware and/or firmware.

The router 110 is preferably configured using the management application130 operating on a remote electronic device (e.g., a user's smartphone),but may additionally or alternatively be configured by any suitablemanner (e.g., by a web interface).

The routers 110 preferably communicate with each other using one or moreversions of the 802.11s protocol (e.g., the modified version describedbelow), using Simultaneous Authentication of Equals (SAE)-basedencryption and hybrid wireless mesh protocol (HWMP) path selection, butmay additionally or alternatively communicate with each other in anymanner.

A person of ordinary skill in the art will recognize that although allor some of the routers 110 may perform routing functions (and/or becapable of performing routing functions), the routers 110 canadditionally or alternatively include access points (e.g., wirelessaccess points such as wireless mesh access points, etc.), repeaters,mesh nodes, switches, and/or any other suitable network devices.

The routers 110 are preferably configured and/or managed by the routermanagement platform 120 (or any suitable remote management platform). Inone example, routers 110 may be configured by altering storedconfiguration profiles in a remote server (part of the router managementplatform 120), after which the stored configuration profiles are pushedto the routers 110. This technique is particularly useful in meshnetworking applications; if the router management platform 120 is awarethat three smart routers are intended for use in a single network, therouter management platform 120 can attempt to bridge the networks of thethree routers regardless of physical location or existing networktopology.

The router management platform 120 may additionally function to manageconnections and/or permissions associated with various networks. Forexample, a user of the router management platform 120 associated withone network may have guest permissions on another network (e.g., usersof LAN1 may be granted permissions with respect to LAN2 via theplatform). As another example, the router management platform 120 may beused for (or may otherwise facilitate) bridging two networks via a VPNtunnel (e.g., two physical networks LAN1a and LAN1b into a singlelogical network), as shown in FIG. 1.

The router management platform 120 may additionally or alternatively beused to collect connection data from the routers 110 and/or provide thisdata (or analysis of this data) to users either via the routers 110 orotherwise (e.g., via a web portal).

The system 100 may additionally include a management application 130that functions to manage routers 110 that are part of a network. Themanagement application 130 is preferably a native application running ona smartphone (e.g., an iOS or Android application), but may additionallyor alternatively be any suitable application (e.g., a web app, a desktopapp, etc.). The management application 130 may be used to perform or aidin router 110 configuration, but may also be used to collect data usedby the method 200. For example, a management application operable on adevice for which location data is desired may collect (and potentiallyanalyzed and/or transmit) data that may be used to perform devicelocalization.

Routers 110 of the same LAN are preferably coupled together as a meshnetwork; e.g., the example network as shown in FIG. 4. Routers 110 maycommunicate to each other and/or to client devices (represented by thecircle ‘D’ symbol) in any manner, e.g., 2.4 GHz Wi-Fi, 5 GHz Wi-Fi,Bluetooth, wired Ethernet.

Information traveling on such a mesh network often may take many paths.The system 100 preferably attempts to path information along the mesh insuch a way as to enhance performance compared to traditional meshnetworking architectures.

The system 100 preferably attempts to enhance mesh networkingperformance by intelligently managing communication between networknodes (e.g., smart routers 110) and between devices communicating withthose nodes (e.g., laptops, smartphones, TVs, etc.). Such managementincludes managing the characteristics of links from router to router andfrom router to device (e.g., channel, radio, broadcast time, etc.) aswell as actively routing information across those links (e.g.,attempting to identify optimal paths across the network for packets).

A router 110 preferably attempts to make every link possible for therouter 110 within the network. For example, a router 110 that sees fourother routers 110 within its wireless range (on both 2.4 GHz and 5 GHz)may create eight links (one for each radio within range). The router 110preferably adopts this approach because the cost for maintaining a linkis relatively low compared to the cost of communicating on a link.Alternatively, the router 110 may not attempt to make every possiblelink. For example, if a router 110 has an Ethernet connection to anotherrouter 110, those two routers 110 may not link wirelessly to each other.As another example, in high density meshes, a router 110 may choose toconnect only to a threshold number of routers 110 nearby (e.g., 15routers of 30 total routers within range).

The channels used by the radios of the routers 110 are preferably set toreduce interference across the network. For example, two routers 110near each other may use the same 5 GHz band (allowing those two routersto communicate with each other AND with devices, but potentially causingcollisions for communication from client devices near both routers 110),but a different 2.4 GHz band (allowing client devices near both routers110 to communicate to one router 110 without interfering withcommunication of other client devices to the other router 110). Router110 channels may be orthogonal or overlapping. For example, routers 110near each other may choose different, but overlapping, 2.4 GHz bands,allowing those routers to still communicate with each other while alsoreducing client device interference.

Router channels may be set in any manner. In one example implementation,a first router 110 selects a 2.4 GHz channel (referred to as 2.4 A) anda 5 GHz channel (5 A) based on a radio survey. Each additional router110 then selects the same 5 GHz channel (5 A) but selects the 2.4 GHzchannel based on a radio survey (e.g., trying to minimize 2.4 GHzinterference between routers 110). Router channels may be setindividually by routers 110, in concert by a set of routers 110, by themanagement platform 120, or by any other agent.

Router channels may also be modified at any time. For example, a router110 having selected a channel by the technique described in thepreceding paragraph may switch its 5 GHz channel in response to heavytraffic on that channel by client devices. Note that in this case, therouter 110 may additionally need to change its 2.4 GHz channel as well(as the router 110 may have to communicate with other nodes on the 2.4GHz band now instead of the 5 GHz band, such as if the other nodes arenot operating on its new 5 GHz channel).

Routers 110 may additionally or alternatively attempt to modify anyother parameters related to inter-router links. For example, routers 110may adjust antenna patterns and/or gain to reduce network interference.Additionally or alternatively, routers 110 may perform beam-forming orbeam-steering (potentially with dynamic gain) for the same purpose.Similar to channels, other router parameters may be set individually byrouters 110, in concert by a set of routers 110, by the managementplatform 120, or by any other agent.

When a device connected to a router 110 attempts to communicate withanother device on the network (or via a gateway of the network), therouter 110 preferably determines an optimal path for the communicationto follow. Routers 110 preferably utilize IEEE 802.11s Hybrid WirelessMesh Protocol (HWMP) and/or a modified version thereof (e.g., such asdescribed below), but may additionally or alternatively use anytechnique for determining pathing.

The following is a description of an example implementation of thepathing technique of the system 100: when a router 110 wants to send apacket to a destination, the router 110 first checks its routing tableto see if it has a current path to the destination. If so, the router110 forwards the packet to the next hop node. If not, the routerinitiates a path discovery process by creating a path request (PREQ)packet. This packet contains the source MAC Address, the HWMP sequencenumber of the originator, a path discovery ID, time-to-live (TTL) andLife Time fields, hop count, the destination MAC address, and a linkmetric. As in 802.11s, this PREQ packet is forwarded across a networkuntil the destination is reached. Based on the PREQ packets received,the destination router(s) 110 send back a path reply (PREP) packet,similar to the PREQ packet. Of note, the link metric and hop count areupdated as the packet moves along the network (essentially taking thepath integral of those values). One or both of the link metric and hopcount are used to determine, at the source router 110, the quality ofthe paths available.

Default 802.11s implementations utilize a metric referred to as an“airtime link metric”, defined as the total data transmission time (intime units) divided by one minus the frame error rate:

$\frac{T}{1 - E}.$While the system 100 may use this metric (or any metric), the system 100preferably uses a novel metric (herein referred to as a Bifrost metric).In contrast to the airtime link metric of 802.11s, the Bifrost metricpreferably accounts for (e.g., takes as input) factors such as datathroughput (e.g., channel transmission rate) and/or channel utilization.The Bifrost metric can additionally or alternatively include any othersuitable factors (e.g., thermal throttling and/or enforced dead transmittime, such as described below).

In one embodiment, the Bifrost metric is determined based on one or morethroughput metrics and/or channel utilization metrics (e.g., associatedwith wireless channels). The Bifrost metric (and/or underlying metricsassociated with the Bifrost metric, such as throughput and/or channelutilization metrics) are preferably associated with (e.g., determinedbased on characteristics of) the links of the network (e.g., wirelesslinks; wired links; aggregated groups of links, such as links sharingcommon endpoints; etc.), such as being determined independently for eachlink of a path within the network. However, the metrics can additionallyor alternatively be associated with nodes, paths, physical regions,and/or any other suitable elements associated with the network. Themetrics can be direction-specific (e.g., for link or path metrics,determined independently for each direction along the link or path) ordirection-nonspecific (e.g., identical for a forward and reverse path,identical for a link from a first to a second device and a link from thesecond to the first device, etc.).

The throughput metrics can include transmission and/or reception rates(e.g., data rates, frame rates, packet rates, etc.), and/or any othersuitable throughputs. The throughput metrics are preferably metricsassociated with (e.g., measured at) the physical layer, but canadditionally or alternatively be associated with the data link layer,network layer, transport layer, and/or any other suitable layer (e.g.,of the OSI layer model). The throughput metrics are preferablydetermined based on a filtered and/or otherwise processed version of thecollected throughput data (e.g., low-pass filtering, Kalman filtering,Hamming windowing, etc.). For example, the throughput metric canrepresent an average (and/or other statistical function, such as median)over time, such as a moving average (e.g., exponentially weighted movingaverage, triangle-number weighted moving average, Hull moving average,unweighted moving average, etc.). However, the metrics can additionallyor alternatively be substantially instantaneous metrics (e.g.,associated with the most recently collected data), can represent maximumvalues (e.g., maximum attained in a particular time window), and/or canbe processed in any other suitable manner. The throughput measurementscan be sampled only during times when data transmission is beingattempted (e.g., while data is queued for transmission, duringtransmission, etc.) or at all times (e.g., whether or not nodes areattempting to transmit data), and/or can be sampled at any othersuitable times. In specific examples, a throughput metric is equal toTx_(avg), the exponentially weighted moving average of the transmitthroughput (e.g., from a node along a link) measured at the physicallayer (TX PHY rate); Rx_(avg), the exponentially weighted moving averageof the receive throughput (e.g., to the node along the reverse directionof the link) measured at the physical layer (RX PHY rate); and/or acombination thereof (e.g., sum, inverse sum, arithmetic and/or geometricmean, minimum or maximum of the two, etc.).

The channel utilization metrics are preferably adjusted to representutilization not attributable to the entity (e.g., node, link, path,etc.) for which the metric is calculated. One formula for such anadjusted channel utilization metric is given as:

$U = \frac{T_{busy} - T_{self}}{T_{active}}$wherein T_(active) is an active time during which the node is active ona wireless channel (e.g., time during which at least one radio of thenode is tuned to the channel) associated with the wireless link;T_(busy) is a total utilization time, within the active time, duringwhich the wireless channel is in use; and T_(self) is a self-utilizationtime, within the active time, during which the node is transmitting onthe wireless channel. Alternatively, can represent time during which thenode is transmitting along a particular wireless link (e.g., thewireless link for which the metric is being calculated) and/or to aparticular endpoint, rather than all time spent by the node transmittingfor any purpose; time during which the channel is used for transmissionsto the node (instead of or in addition to time spent for transmissionsfrom the node); and/or any other suitable self-utilization timeassociated with the node, wireless link, and/or other entity. However,the channel utilization metrics can additionally or alternativelyinclude any other suitable adjustments (e.g., in place of or in additionto the T_(self) term), and/or can be unadjusted (e.g., can exclude theT_(self) term).

In one implementation of this embodiment, the Bifrost metric is computedas follows: at each node, a base metric is computed as the inverse of athroughput metric D. The base metric is then modified by terms includinga channel utilization metric U, preferably an adjusted channelutilization metric that represents the channel utilization not due tothat node (e.g., amount of traffic on the channel not due to the node,fraction of time the channel is unavailable for the node to transmit on,etc.). Two formulas for such a metric M are given as:

$M = \frac{C + U}{D}$ and/or $M = \frac{C}{D\left( {1 - U} \right)}$where C is some constant (e.g., kept fixed for all calculations of themetric M for all nodes and/or links, constant for a given node and/orlink but varying between different nodes and/or links, etc.), T_(busy)is time the channel was in use, T_(self) is time the channel was in usedue to communication from the node itself, and T_(active) is the timethe total radio spent on the channel. Specific examples of the metriccan include:

${M = \frac{C + \frac{T_{busy} - T_{self}}{T_{active}}}{{Tx}_{avg}}};$${M = \frac{C + \frac{T_{busy} - T_{self}}{T_{active}}}{{Rx}_{avg}}};$${M = \frac{C}{{Tx}_{avg}\left( {1 - \frac{T_{busy} - T_{self}}{T_{active}}} \right)}};$and/or$M = \frac{C}{{Rx}_{avg}\left( {1 - \frac{T_{busy} - T_{self}}{T_{active}}} \right)}$As can be seen, this metric decreases with increasing throughput (i.e.,faster connections result in lower metric values) and increases alongwith channel traffic (i.e., less traffic results in lower metricvalues). This metric also exhibits reduced sensitivity (e.g., isinvariant to, changes less than a metric using an unadjusted channelutilization metric, etc.) contributions of the node measuring the metricto traffic.

The Bifrost metric can optionally include one or more parametersrepresenting hardware conditions, such as temporary performancerestrictions. For example, the metric can include a radio throttlingparameter, such as T_(throttle), representing a throttling time withinthe active time during which radio transmission was prevented due tothrottling, and/or f_(throttle), representing the fractional amount ofradio throttling (e.g., the fraction of time during which radiothrottling occurred, wherein

$\left. {f_{throttle} = \frac{T_{throttle}}{T_{active}}} \right).$Radio throttling can be used, for example, to prevent and/or alleviateradio overheating (e.g., by reducing radio transmission time, therebyreducing the thermal energy generated by the radio). In a firstvariation, the hardware condition parameters (e.g., throttlingparameter) are included in the channel utilization metric, such as

$U = {{\frac{T_{busy} - T_{self} + T_{throttle}}{T_{active}}\mspace{14mu}{or}\mspace{14mu} U} = {\frac{T_{busy} - \left( {T_{self}f_{throttle}} \right)}{T_{active}}.}}$In a second variation, the hardware condition parameters are included inthe overall Bifrost metric, such as

${M = \frac{C + U}{D\mspace{11mu} f_{throttle}}},{M = \frac{C + {U\text{/}f_{throttle}}}{D}},{{{and}\text{/}{or}\mspace{14mu} M} = {\frac{C}{D\mspace{11mu}{f_{throttle}\left( {1 - U} \right)}}.}}$However, the Bifrost metric can include any other suitable hardwarecondition parameters in any other suitable manner.

After the Bifrost metric has been calculated for a given link (e.g.,defining the link cost), it's added to the sum of previous metrics alongthe path, such that the eventual metric becomes a path integral forBifrost metric values along the path (e.g., defining the path cost). Asdescribed above, the path with the smallest Bifrost metric value is the‘best’ path. In one variation, nodes of a path (e.g., all nodes, allexcept an initial and/or terminal node, etc.) each calculate a linkmetric for a link associated with the node (e.g., originating from orterminating at the node), receive a partial path metric (e.g., thecumulative sum of link metrics along a portion of the path, such as fromthe initial or terminal node to the node transmitting the partial pathmetric) from a neighboring node (e.g., next or previous node along thepath), add the calculated link metric to the partial path metric, andtransmit the new partial path metric to the opposing neighbor (e.g.,continuing along the path or the reverse path).

In one example, the terminal node of a path (node A) transmits (e.g., inresponse to receiving a path request) a path reply frame, preferablyincluding a metric field (e.g., set to zero) to the previous node alongthe path (node B). In response to receiving the path reply frame, node Bdetermines the Bifrost link metric associated with the link from itselfto node A (B-A link), updates the partial path metric by adding the linkmetric to the value from the metric field, and transmits an updated pathreply frame (e.g., including the updated partial path metric) to theprevious node along the path (node C). Analogously, node C calculatesthe C-B link metric, updates the partial path metric, and transmits apath reply including the updated metric (representing the cost from C toA via B) to the previous node along the path. In this example, the pathreply is propagated back to the initial node of the path. However, anynode can optionally ignore or otherwise act upon receipt of a path reply(e.g., based on its metric). For example, if a first node receives twopath replies for path segments from the first node to a second node,each via a different path (e.g., different series of intermediarynodes), it can optionally propagate the path reply with the better(e.g., lower) metric and ignore the path reply with the worse metric(e.g., as shown in FIG. 5C).

As shown in FIG. 5A, a client device (D) attempts to send information toa cable modem on a mesh network having link metric values (e.g., linkcosts, such as costs which can be added to determine a path cost) asshown. The node connected directly to the client device (e.g., the APfor the client device) sends a path request (PREQ) message (e.g., for apath to the cable modem, a path to the gateway node connected to thecable modem, etc.), which propagates through the mesh network, possiblyreaching the gateway node from multiple neighboring nodes (e.g., asshown in FIG. 5B). In response to receiving the path request from eachneighbor, the gateway node sends a path reply (PREP) message to theneighbor from which the PREQ was received, including a path metric(e.g., zero in all cases, because the path begins at the gateway node).Each node receiving a PREP calculates the link metric associated withthe node from which the PREP was received (e.g., the link cost fortransmitting from itself to the node from which the PREP was received),adds the link metric to the path metric in the received PREP, andpropagates the PREP (with the updated path metric) along the reversepath (e.g., as shown in FIG. 5C). The node connected directly to theclient device receives one or more PREPs, calculates and adds the finallink metric, and selects the path with the lowest total metric (e.g., asshown in FIG. 5D). Communication from the client device to the cablemodem may be routed along this path.

The Bifrost metric preferably increases with (e.g., is directlyproportional to) the airtime cost of queueing a given unit of data on aparticular peer link, and is preferably comparable across link frequency(e.g., 2.4 and 5 GHz). The Bifrost metric can optionally be used (ormodified) to account for Ethernet link quality, allowing comparisons notjust across link frequency but also across wired and wireless links aswell. The Bifrost metric can additionally or alternatively be set equalto zero (e.g., representing a no-cost link) or a small constant forEthernet links, and/or can treat Ethernet links in any other suitablemanner (or not be applied for Ethernet links).

In some embodiments, the mesh network includes multiple links betweenthe same nodes, such as for nodes with multiple link interfaces (e.g.,multiple radios capable of independent, simultaneous communication,multiple Ethernet ports, both radios and Ethernet ports, etc.). Forexample, two nodes can be simultaneously connected by multiple wirelesslinks (e.g., in different bands, such as 2.4 GHz, 5.2 GHz, and/or 5.8GHz) and/or Ethernet links. In one variation, each of these physicallinks can be treated independently (e.g., a link metric can bedetermined for any or all of them independently; paths through thenetwork can specify the physical links individually, rather than justthe endpoints of the links; etc.).

In a second variation, multiple physical links sharing endpoints (e.g.,all such links, all such wireless links, a subset of such links, etc.)can be considered (e.g., from a link assessment and/or path selectionperspective) as a single effective link (e.g., treated as a linkaggregation group), wherein a single link metric associated with theeffective link is determined, and paths specify the effective linkrather than any of the specific underlying physical links within it.This variation can enable individual mesh nodes (and/or linked pairs ofnodes) to select the optimal physical link(s) for communication with agiven neighbor, without interfering with higher-level path selection(e.g., including enabling multiplex communication with the neighbor). Inone example of this variation, each node of an effective link isspecified by a single identifier such as a MAC address (e.g., highest orlowest MAC address; MAC address of the first-connected physical link;MAC address associated with a predetermined interface, such as a firstEthernet port or first wireless radio of the node, optionally even ifthe effective link does not include a physical link associated with thepredetermined interface; etc.).

In this second variation, the effective link metric (e.g., link cost)associated with the effective link is preferably determined based on thephysical link metrics of all or some of the underlying physical links.For example, the effective link metric can be equal to the best physicallink metric, the sum of the physical link metrics, the inverse sum(e.g., inverse of the sum of the inverses) of the physical link metrics,the arithmetic and/or geometric mean of the physical link metrics,and/or any other suitable function of the physical link metrics (or of asubset thereof, such as the best two or three such links). The effectivelink metric can additionally or alternatively be determined based onperformance of the effective link (e.g., simultaneous use of multiplephysical links of the effective link) rather than individual performanceof the underlying physical links. However, the effective link metric canadditionally or alternatively be determined in any other suitablemanner.

In one implementation of an invention embodiment, routers 110 include anautoprobing system triggered by Bifrost metric values. Because linksthat are idle or have ‘bad’ metrics may not see substantial traffic,nodes connected via these links may not receive regular metric updates(and therefore may not necessarily have the ability to modifyconfiguration settings iteratively to improve metric values). Theautoprobing system functions to generate traffic on links that are idle(e.g., below some activity threshold) and/or ‘bad’ (e.g., Bifrost metricbelow some threshold).

Alternative to the Bifrost metric, the system 100 may utilize a learned(or otherwise tuned) link metric that, in aggregate, promotes aparticular goal across the network. For example, a learned link metricmay be set based on the average latency across a network.

Tuning the learned link metric may include utilizing one or more of:supervised learning (e.g., using logistic regression, using backpropagation neural networks, using random forests, decision trees,etc.), unsupervised learning (e.g., using an Apriori algorithm, usingK-means clustering), semi-supervised learning, reinforcement learning(e.g., using a Q-learning algorithm, using temporal differencelearning), and any other suitable learning style. Each module of theplurality can implement any one or more of: a regression algorithm(e.g., ordinary least squares, logistic regression, stepwise regression,multivariate adaptive regression splines, locally estimated scatterplotsmoothing, etc.), an instance-based method (e.g., k-nearest neighbor,learning vector quantization, self-organizing map, etc.), aregularization method (e.g., ridge regression, least absolute shrinkageand selection operator, elastic net, etc.), a decision tree learningmethod (e.g., classification and regression tree, iterative dichotomiser3, C4.5, chi-squared automatic interaction detection, decision stump,random forest, multivariate adaptive regression splines, gradientboosting machines, etc.), a Bayesian method (e.g., naïve Bayes, averagedone-dependence estimators, Bayesian belief network, etc.), a kernelmethod (e.g., a support vector machine, a radial basis function, alinear discriminate analysis, etc.), a clustering method (e.g., k-meansclustering, expectation maximization, etc.), an associated rule learningalgorithm (e.g., an Apriori algorithm, an Eclat algorithm, etc.), anartificial neural network model (e.g., a Perceptron method, aback-propagation method, a Hopfield network method, a self-organizingmap method, a learning vector quantization method, etc.), a deeplearning algorithm (e.g., a restricted Boltzmann machine, a deep beliefnetwork method, a convolution network method, a stacked auto-encodermethod, etc.), a dimensionality reduction method (e.g., principalcomponent analysis, partial lest squares regression, Sammon mapping,multidimensional scaling, projection pursuit, etc.), an ensemble method(e.g., boosting, bootstrapped aggregation, AdaBoost, stackedgeneralization, gradient boosting machine method, random forest method,etc.), and any suitable form of machine learning algorithm. Eachprocessing portion of the method 200 can additionally or alternativelyleverage: a probabilistic module, heuristic module, deterministicmodule, or any other suitable module leveraging any other suitablecomputation method, machine learning method or combination thereof.However, any suitable machine learning approach can otherwise beincorporated into link metric learning.

In another departure from the 802.11s standard, multicast and broadcastframes transmitted by the routers 110 preferably include an additionalfield specifying the band and/or channel (e.g., and/or the radio, suchas a radio associated with a particular band) on which a router 110 sawa path announcement (e.g., path request or PREQ, path reply or PREP,etc.). In traditional 802.11s implementations, passing an announcementfrom one radio, band, and/or channel to another on the same node wouldresult in a change of the sequence number. Consequently, the message isnow treated differently by the network, and loops may occur. By trackingthe radio field, the system 100 can allow paths containing links inmultiple bands without suffering the looping issues present in the802.11s implementation. Alternatively, some or all frames (e.g.,multicast and/or broadcast frames) may not include this additionalfield.

Though not explicitly discussed previously, nodes in 802.11s systemstrack PREQs based on whether they have been received before or not(discarding them if so). The system 100 preferably implements a novelmethod of storing frame information and deciding whether to forwardmulticast frames that departs from the traditional 802.11simplementation. For each multicast frame received, routers 100preferably hash a portion (e.g., unique portion) of the frame (e.g., thesource address of the frame and/or packet header, the entire frameand/or packet header, the frame and/or packet contents, the entire frameand/or packet, etc.) and store the hash along with an expiration timer.The router 100 preferably maintains a list of the several most recentmulticast frames received from each source (e.g., 16) along with a TTLvalue and an expiration time. If the router 100 receives a multicastframe from a source within the expiration time of a record stored withthat router 100, the router 100 decrements the stored TTL and forwardsthe frame. When the stored TTL reaches zero, the frame will be discardedinstead of forwarded. As each node has an RCU protected hash table ofthese lists, lookup is easily parallelizable, providing efficiency gainsover standard 802.11s implementations. This multicast cache may beshared between wireless and wired interfaces, preventing loops andenabling both wired and wireless connections to be used in the network.

In a variation of an invention embodiment, the system 100 includes anadditional layer on top of the link metric system described above. Inthis variation, routers 110 maintain a distributed Quality of Service(QoS) based system where a given router 110 will issue traffic creditsto other nodes in their wireless collision domain. These traffic creditsmay place restrictions on when neighboring nodes can send data to arouter 110, allowing the system 100 to reduce collisions in acoordinated fashion. Similarly to link metrics, the system 100 mayutilize machine learning to distribute and/or regulate traffic creditsin such a system.

The system 100 preferably uses link metrics for routing as describedabove, but the system 100 may additionally or alternatively usecalculated link metric values as a proxy for live throughput values asan estimation of network health. For example, a network health metricfor a network with L links may be found as follows:

$H = {\frac{1}{L}{\sum\limits_{l}^{L}\;{M_{l} \times U_{l}}}}$where U_(l) is a utilization factor (this is essentially an average linkmetric weighted by link utilization). The system 100 may additionally oralternatively use link metric values to estimate network health in anymanner.

In addition to the aforementioned techniques for increasing networkperformance, the system 100 may additionally or alternatively performtechniques to force client devices to move access points. This may beuseful, for example, to better distribute client devices across wirelessaccess points (APs). For many mobile electronic devices (e.g., mostsmartphones), device users (and APs, for that matter) have very littlecontrol over how the device chooses a wireless network. In most cases,wireless clients connect to a network and remain connected to it untilsignal quality (or another metric of communication quality) drops belowa static threshold, at which point the clients disconnect and search forthe strongest signal. In networks having APs with overlapping wirelessranges (especially dense mesh networks), this means that frequently aclient initially connected to AP1 may move closer to AP2 than AP1, butwill still remain connected to AP1 (because AP1 signal hasn't droppedbelow a threshold).

Forcing a client disconnect preferably causes such a device to re-checkwhat the strongest AP is and connect to it. Note that while AP signalstrength is correlated with distance from the AP, interference and noisemay mean that the strongest AP is not necessarily the closest. Forexample, a smartphone is in a living room near a wall, and the livingroom AP is ten feet away. A bedroom, having a bedroom AP, is on theother side of the wall. In such a situation (based in part onattenuation due to the wall), the smartphone may see the living room APas “closer” (i.e., it sees a higher signal strength). Forcing a clientconnection change may have numerous changes beyond localization,including optimization of mesh networking parameters, network loadbalancing, and/or wireless interference management. For example, inorder to enhance network performance, a client can be forced todisconnect from a first AP and to instead connect to a second AP, evenif the client-second AP link is worse (e.g., associated with lowerthroughput) than the client-first AP link. In a first specific exampleof this example, the path cost from the first AP to the internet is muchhigher than the cost from the second AP to the internet, such that theoverall client-internet path cost is lower when the client is connectedto the second AP. In a second specific example, the link between thefirst AP and a second client (e.g., a client that is unable to connectto the second AP) can be improved by disconnecting the first client fromthe first AP (e.g., thereby enabling strong beamforming to enhance thequality of the second client-first AP link). However, client connectionchanges can additionally or alternatively be controlled in any othersuitable manner for any other suitable reason.

A router 110 may force a client connection change in any manner. In afirst example, the router 110 may remove a client from an access pointby blocking the MAC address (or another identifier) of the client at theaccess point and actively kicking the client off of the access point;this prevents the client from reconnecting until the MAC address isunblocked. Alternatively, the router 110 may disconnect a client from anAP without preventing the client from rejoining that AP.

In a second example, a router 110 may rescind credentials for aparticular device. In the second example, the router 110 may includerescind credentials in any manner; for example, by rescinding access toan AP using a set of credentials associated with the device or with auser of the device. In some cases, these credentials may be device oruser specific (e.g., a certificate stored on a smartphone, ausername/password) but additionally or alternatively, the credentialsmay be non-device-specific (e.g., an AP password for a WPA-2 personalsecured AP).

The router 110 may additionally or alternatively disconnect a clientfrom an AP in any other manner (e.g., by lowering transmit power of theAP to force client roaming). Note that the system 100 may, bycontrolling the access points a client can connect to, force a client toconnect to a specific AP (or one of a set of APs). For example, a meshnetwork may include four APs within range of a device: AP1, AP2, AP3,and AP4. By blocking the device from connecting to AP1 and AP2, thenetwork may force the device to connect to one of AP3 or AP4. Likewise,AP3 could also be blocked to force the device to connect to AP4.

The preceding examples are operable even when APs have limited controlover client roaming. However, in some cases, a network may have moresubstantial control over client roaming (or may even be able todesignate which network the device connects to explicitly). In thesecases, the system 100 may additionally or alternatively modify clientroaming parameters and/or direct the device to connect to a specific APor a set of APs.

The system 100 may direct AP modification in any manner. For example,routers 110 may store link quality metrics for the links between APs andclient devices, and may disconnect client devices if they fall below athreshold. As another example, routers 110 may evaluate client links bylatency to the client (this latency may be scaled based on the type ofclient device).

The system 100 may attempt to distribute clients among routers 110 (andradios of those routers 110) based on any number of factors, includingthe type of device (e.g., smartphone, laptop, etc.), model of device(e.g., Galaxy, iPhone), bandwidth usage of device (e.g., high bandwidth,low bandwidth), mobility of device (e.g., as determined by RSSI changesor by AP changes), frequency of communication, etc.

In addition to actual client link quality metrics, the system 100 mayadditionally or alternatively distribute client devices based oncontextual or historical data. For example, a computer used during theday for large downloads and at night for gaming may be switched betweena connection (e.g., a wireless link to an AP, a path through the networkto the internet, etc.) having high throughput and/or high latency(during the day) and one having low throughput and/or low latency(during the evening).

While the system 100 has been described for situations in which trafficgenerally has a known destination, there are circumstances in whichtraffic may have multiple potential destinations (e.g., the case inwhich a mesh network has several gateways to the internet). In avariation of an invention embodiment, the system 100 may perform sharingtraffic across multiple internet connections. For example, the system100 may designate primary and secondary (and tertiary, and so on)internet connections, used by all devices on a particular network. Thesystem 100 may additionally or alternatively designate internetconnections by device (e.g., all devices in the 192.168.1.xxx subnet usea particular connection, all smartphones use a particular connection,etc.), or by TCP stream (or at any other sub-device resolution level);for example, high bandwidth, latency insensitive applications (e.g.,streaming video) may use a first connection, while low bandwidth,latency sensitive applications (e.g., real-time online gaming) may use asecond connection.

Traffic sharing may be performed based on any suitable input data. Forexample, traffic sharing may include altering NAT configuration based onavailable bandwidth (e.g., a particular connection is only used until abandwidth cap is reached), price (e.g., expensive connections may beused only when necessary for a particular application), or any othercriteria. Traffic sharing agreements are preferably determined by therouter management platform 120, but may additionally or alternatively bedetermined by any suitable entity.

Traffic sharing can also be accomplished via network load balancingalgorithms, whereby IP traffic is distributed over the multiple internetconnections in order to meet one or more network goals. Examples ofnetwork goals may include reducing response time for one or more deviceson the network, increasing bandwidth available to one or more devices onthe network, increasing performance for particular services or types oftraffic on the network, increasing reliability of internet access fordevices on the network, etc. A first example of a network load balancingalgorithm for traffic sharing is a round robin algorithm. The roundrobin algorithm allocates a first IP traffic request to a randomlyselected first internet connection, a second traffic request to a secondinternet connection that is randomly selected except that it excludesthe first, and so on until all internet connections have been allocatedat least once, at which point the cycle repeats. Round robin works wellwhen most traffic requests are roughly equal in bandwidth demand andduration. A second example of a network load balancing algorithm isdynamic round robin. Dynamic round robin works similarly to the baseround robin algorithm except that the allocation step is distributedaccording to a weighting scheme discerned from real-time internetconnection performance. Dynamic round robin can eschew the problem ofmultiple high traffic requests being routed over the same internetconnection. A third example of a network load balancing algorithm is apredictive algorithm. A predictive algorithm can monitor real-timeinternet connection characteristics (e.g., which internet connectionshave the fewest IP traffic requests on them, which internet connectionshave the largest data stream allocations on them, etc.) and historicalinternet connection characteristics (e.g., a time series of monitoreddownload and upload speeds over a recent time period) in order todetermine which internet connections are improving or declining inperformance over time (as quantified in a metric of performance), canfeed these metrics of performance into a dynamic weighting scheme, andcan allocate new IP traffic requests according to the dynamic weightingscheme. Alternatively, any suitable network load balancing algorithm canbe implemented by the system 100.

The manner in which the system 100 performs load balancing can bepredetermined (e.g., traffic can be proportionally distributed acrossinternet connections), dynamically determined (e.g., at the time of auser request, the particular request can assign a priority, and then therouters can handle load performance in accordance with the priorityhierarchy of all network traffic), or determined in any other suitablemanner.

Embodiments of the method 200, described below, can optionally implementsome or all of the network assessment and/or management techniquesdescribed above regarding the system 100. Such techniques are preferablyperformed using the system 100, but can additionally or alternatively beperformed using any other suitable network or other system.

2. Method for Enhanced Mesh Networking

A method 200 for enhanced mesh networking preferably includes performingnetwork analysis S210, configuring router link parameters S220, andmanaging routing paths S230, as shown in FIG. 6. The method 200 mayadditionally or alternatively include managing client links S240 and/orany other suitable elements.

The method 200 preferably functions to effectively configure and managea mesh network (e.g., a network operating on multiple frequency bands,and potentially bridged by Ethernet links) by efficiently assigningrouter communication parameters and determining routing paths based ondiscovered link metrics.

The method 200 is preferably performed by the system 100, but mayadditionally or alternatively be performed by any mesh network (e.g.,any multi-band mesh network).

S210 includes performing network analysis. S210 functions to determinenetwork state information. For example, S210 may function to determinethe number of mesh nodes (e.g., routers) in a network, individualconfiguration details for each node (e.g., wireless communicationchannels, channel width, Ethernet capabilities, wireless mode,encryption type, QoS configuration, DHCP configuration, NATconfiguration), their proximity to one another, the connection type andquality between nodes, the number of client devices in a network,individual configuration details for each client device (e.g., clienttype, client AP, client wireless communication channel, client Ethernetcapabilities), connection type and quality between clients and nodes,overall network throughput, WAN gateway details, etc.

S210 may include performing network analysis in any manner. For example,S210 may include querying devices on the network, performing networksurveys from devices on the network, requesting user input, or any othertechnique. S210 may additionally or alternatively include loggingnetwork data and using this data to perform network analysis. Forexample, S210 may including logging link (either inter-router links orclient-router links) throughput and error rate to determine linkquality.

S210 is preferably performed by one or more routers of a mesh network,but may additionally be performed by or aided in performance by a mobileclient device (e.g., a smartphone) running a network monitoring app. Forexample, S210 may include collecting network data from a smartphone as auser moves around in a mesh network.

S210 may additionally or alternatively include requesting networkanalysis data from a network user. For example, S210 may include askinga user to notify a management app on a client device if the network isever not working ideally (triggering the network to log data particularto the client device and/or time).

S210 is preferably run during initial network configuration, but mayadditionally or alternatively be run at any time in order to betterinform network configuration.

S220 includes configuring router link parameters. S220 functions toconfigure communication links between routers.

For each mesh node, S220 preferably includes initializing links to everyother mesh node within communications range. These links may then beused (or not used) depending on routing needs. Additionally oralternatively, S220 may include initializing links to only a subset ofmesh nodes within communication range. For example, S220 may includeinitializing links only to nodes of a certain type, nodes with asignal-to-noise (SNR) above some threshold, nodes with a Rx/Txthroughput above some threshold, nodes not connected via Ethernet, etc.As a second example, if there are m nodes within range of the node, S220may include initializing links to n of m nodes based on some criteria(e.g., the five nodes with lowest latency).

S220 may additionally or alternatively include modifying wirelesscommunication channels of mesh nodes. S220 preferably includes settingwireless channels to reduce interference and increase throughput of thenetwork, but may additionally or alternatively set wireless channels toachieve any goal.

S220 may include, for example, setting nodes initially to the same 5 GHzchannel, but setting nodes to diverse 2.4 GHz channels. Such aconfiguration may enable nodes to communicate with each other (andpotentially client devices) over the 5 GHz band, while optimizing the2.4 GHz band to communicate with client devices.

In another example, S220 includes determining D_(c2.4) (the percentageof airtime arising from router-client communication on the 2.4 GHzband), D_(c5) (the percentage of airtime arising from router-clientcommunication on the 5 GHz band), D_(m2.4) (the percentage of airtimearising from router-router communication on the 2.4 GHz band), andD_(m5) (the percentage of airtime arising from router-routercommunication on the 5 GHz band) for each node of the network, as wellas P_(2.4) and P₅ (signal proximity; e.g., as measured by beacon SNR).In this example, S220 preferably sets the 2.4 and 5 GHz channels of eachnode C_(2.4) and C₅ by attempting to minimize the following:

f₅ + f_(2.4) where$f_{2.4} = {{\sum\limits_{{l,k}{2.4\mspace{11mu}{GHz}}}\;{{K_{1}\left( {K_{2} + {B\left\lbrack {C_{l},C_{k}} \right\rbrack}} \right)}\left( {D_{c,l} + D_{c,k}} \right)P_{l,k}}} + {{K_{3}\left( {K_{4} - {B\left\lbrack {C_{l},C_{k}} \right\rbrack}} \right)}\left( {D_{m,l} + D_{m,k}} \right)P_{l,k}}}$$f_{5} = {{\sum\limits_{{l,k}{5\mspace{11mu}{GHz}}}{{K_{5}\left( {K_{6} + {B\left\lbrack {C_{l},C_{k}} \right\rbrack}} \right)}\left( {D_{c,l} + D_{c,k}} \right)P_{l,k}}} + {{K_{7}\left( {K_{8} - {B\left\lbrack {C_{l},C_{k}} \right\rbrack}} \right)}\left( {D_{m,l} + D_{m,k}} \right)P_{l,k}}}$where K₁ . . . K₈ are constants, B is a binary operator on channels(e.g., B is zero if C_(l)≠C_(k) and one if C_(l)=C_(k)). This metric isminimized when nearby nodes with a lot of router-client communication ona given band are on different channels and when nearby nodes with a lotof router-router communication on a given band are on the same channel.Of course, since router-to-router communication may be highly dependenton channel settings, this metric may be evaluated iteratively accordingto any minimization algorithm.

As a third example, S220 may include setting network channels byrandomly varying channel settings (or otherwise varying channelsettings) and monitoring network performance using a machine learningalgorithm, eventually learning an optimal network channel state.

S220 may additionally or alternatively include restricting traffic on aparticular band for a particular purpose. For example, S220 may include,on a given node, limiting 5 GHz traffic to backhaul traffic and 2.4 GHztraffic to router-to-device traffic.

S220 may additionally or alternatively include attempting to modify anyother parameters related to inter-router links. For example, S220 mayadjust antenna patterns and/or gain to reduce network interference.Additionally or alternatively, S220 may include configuring nodes toperform beam-forming or beam-steering (potentially with dynamic gain)for the same purpose.

S230 includes managing routing paths. S230 functions to determine pathsacross the network (e.g., across the mesh and/or Ethernet links) for agiven source and destination. S230 preferably includes managing routingpaths according to the IEEE 802.11s Hybrid Wireless Mesh Protocol (HWMP)(e.g., according to a modified version of the protocol, such as themodified versions described above regarding the system 100), but mayadditionally or alternatively use any technique for determining pathing.S230 may, for example, include creating and/or updating routing pathsusing reactive and/or proactive routing techniques as described in theIEEE 802.11s standard, with the same deviations from this standard asdescribed in the system 100 sections on pathing.

S230 preferably includes maintaining at each node a multicast framedataset, the dataset containing historical multicast information foreach source. For example, the dataset may contain references to the 16most recent multicast frames for each source seen by the node. Eachreference is preferably linked to a time stamp; if the difference intime between frames from the same source is below a threshold, thesecond frame may not be forwarded by the node. Alternatively, thedataset may maintain TTL for each entry (e.g., so if subsequent frames(such as a second frame, third frame, fourth frame, etc.) are receivedless than the threshold time after a first frame, each forwarddecrements TTL, and not all frames may be forwarded). This multicastcache is preferably stored as an RCU protected hash table, leading toeasily parallelizable lookup and providing efficiency gains overstandard 802.11s implementations. Likewise, this cache is preferablyshared across communication modalities.

S230 preferably includes determining routing paths using the Bifrostmetric described in the sections on the system 100, but may additionallyor alternatively utilize any suitable link metric(s). S230 canoptionally include implementing the STAMP technique described below, butcan additionally or alternatively use any other suitable techniques toenable incorporation of Ethernet segments (e.g., including legacyEthernet devices incompatible with typical mesh networks) into the meshnetwork, or can use no such technique.

In a variation of an invention embodiment, S230 includes routing trafficaccording to a distributed Quality of Service system, where nodes issuetraffic credits to other nodes in their wireless collision domain. Thesetraffic credits may place restrictions on when neighboring nodes cansend data to a node, allowing the network to reduce collisions in acoordinated fashion.

In addition to calculating link metrics for links of the network, themethod 200 may additionally or alternatively include estimating networkhealth and/or throughput based on the overall link metrics of thenetwork. For example, the method 200 may include measuring the network'stotal throughput, or a weighted average of throughput per node (weightedby node importance and/or traffic).

S240 includes managing client links. S240 may include modifying anyaspect of node-to-client-device communication; for example, QoSparameters, connection type (e.g., 802.11g vs. n vs. ac), connectionmodality (e.g., Ethernet vs. Wi-Fi vs. Bluetooth), connection speed,etc.

S240 may additionally or alternatively include optimizing client linksby moving client devices from one node to others. This may be used tomore evenly distribute client devices according to bandwidthavailability and interference likelihood. Note that the same algorithmsused to determine channels may also be used with varying client APconnections. For example, the previous formulae f₅+f_(2.4), where

$f_{2.4} = {{\sum\limits_{{l,k}{2.4\mspace{11mu}{GHz}}}\;{{K_{1}\left( {K_{2} + {B\left\lbrack {C_{l},C_{k}} \right\rbrack}} \right)}\left( {D_{c,l} + D_{c,k}} \right)P_{l,k}}} + {{K_{3}\left( {K_{4} - {B\left\lbrack {C_{l},C_{k}} \right\rbrack}} \right)}\left( {D_{m,l} + D_{m,k}} \right)P_{l,k}}}$$f_{5} = {{\sum\limits_{{l,k}{5\mspace{11mu}{GHz}}}{{K_{5}\left( {K_{6} + {B\left\lbrack {C_{l},C_{k}} \right\rbrack}} \right)}\left( {D_{c,l} + D_{c,k}} \right)P_{l,k}}} + {{K_{7}\left( {K_{8} - {B\left\lbrack {C_{l},C_{k}} \right\rbrack}} \right)}\left( {D_{m,l} + D_{m,k}} \right)P_{l,k}}}$may be varied not only in AP channel, but by forcing clients to joinparticular APs, D_(c) for affected APs will be modified.

S240 may include forcing a client disconnect, preferably causing such adevice to re-check what the strongest AP is and connect to it. Aspreviously discussed, forcing a client connection change may havenumerous changes beyond localization, including optimization of meshnetworking parameters, network load balancing, and/or wirelessinterference management.

S240 may include forcing client connection changes in any manner, asdiscussed in the sections covering the same techniques in thedescription of the system 100. S240 preferably includes distributingclients across nodes in a manner that maximizes both overall networkthroughput and reliability as well as performance for individual deviceson the network. S240 may include distributing clients across nodes basedon any number of factors, including the type of device (e.g.,smartphone, laptop, etc.), model of device (e.g., Galaxy, iPhone),bandwidth usage of device (e.g., high bandwidth, low bandwidth),mobility of device (e.g., as determined by RSSI changes or by APchanges), frequency of communication, historical connection qualitydata, historical bandwidth usage, etc.

S240 may additionally or alternatively include requesting manual userintervention. For example, S240 may include directing a user to rotateand/or relocate one or more nodes of the network in order to increasenetwork efficiency.

S240 may additionally or alternatively include requesting any type ofuser network configuration intervention (including providinginstructions for changing network device configurations in software,rerouting Ethernet cables, moving wireless access points, etc.). S240preferably enables the user (most preferably by means of softwareoperating in conjunction with a remote management platform, butalternatively otherwise) to easily implement the desired configurationchanges. In a second example, the user can confirm that the networkconfiguration performed by the earlier steps are appropriate. In thissecond example, the user is given instructions through software on anexternal electronic device; per the instructions, the user can thenreconfigure network configuration settings when the reconfigurationincludes physical modifications to network features (e.g., disconnectingrouters which were previously physically tethered by an Ethernet cable).

The method 200 (and/or any suitable elements thereof) can be performedonce, repeatedly (e.g., periodically, sporadically, in response totrigger occurrence, etc.), and/or with any other suitable timing. Forexample, the method 200 can include continuously assessing link metricsand repeatedly (e.g., periodically, in response to PREQ receipt, etc.)re-determining routing paths based on the metrics.

3. Segment Table Announced Mesh Protocol (STAMP)

A common problem in traditional mesh networks that include legacyEthernet segments is that many Ethernet devices with more than oneEthernet port, including switches, routers, bridges and client devicescontain a structure generally referred to as an address resolution listor forwarding database. These devices use this ARL or FDB in order toquickly determine which of their multiple ports leads to a given MAC.Given that Ethernet frames only contain two addresses—destination andsource—and the Ethernet protocol is connectionless, the only means ofdetermining where a given MAC is located on an Ethernet network is bysnooping the source address of frames coming from that port.

A traditional Ethernet switch, upon receiving a frame, compares it tothe addresses currently in its ARL, and if it finds it, will thendeliver it to the port noted in the ARL. If it does not find the frame,it will flood it to every port other than the one it came in on. Havingdone this, it notes that the source address on the frame is present onwhichever port it came in on.

This is problematic in mesh networks, because mesh networks may notguarantee to deliver frames to attached Ethernet segments in adeterministic fashion. This means that Ethernet switches in such asegment may become confused by traffic that appears to come from randomlocations. Moreover, since every mesh node bordering an Ethernet segmentwill see traffic that has come from the mesh when it lands on thesegment, they may decide to take the frames and inject them back intothe mesh. This traffic then moves through the mesh and is reinsertedback into the Ethernet segment repeatedly, causing the network toeventually become clogged by looping frames.

Problems of looping are solved in wired Ethernet networks using thewell-known Spanning Tree Protocol (STP). Unfortunately, since this workson a per-bridge-port basis, it is not well suited to meshes where asingle bridge port may represent dozens of peer links. Moreover, meshesmay have intrinsically cyclic topologies, and derive many of theirreliability benefits from the multiple paths allowed by such cyclicstructures. Spanning Tree Protocol, which is designed to make a networkacyclic, may not be a good fit for such networks, even if it is extendedto handle mesh links on a per-peer-link basis.

Problems of looping frames in wireless mesh networks may be solvedbecause the routing algorithm does not allow unicast frames to loop,each frame has a mesh header including a mesh time-to-live, andmulticast frames are checked against a hash table of recent multicastframes, allowing them to loop through each node only once. However,Ethernet's small header may not allow this technique to be used.

Segment Table Announced Mesh Protocol (STAMP) (e.g., Spanning TreeAnnounced Mesh Protocol) is an adjunct protocol which builds uponfacilities provided by the IEEE 802.11s mesh networking standard inorder to make it possible to deterministically deliver frames from meshnetworks to legacy IEEE 802.3 Ethernet clients.

STAMP preferably includes determining one or more segments of thenetwork (e.g., the LAN). Each segment is preferably a portion ofnetwork-connected devices that are mutually connected by a homogeneousconnection type (e.g., wherein all devices of a wireless segment areconnected by wireless links, all devices of an Ethernet segment areconnected by Ethernet, etc.), such as shown in FIGS. 7B-7C. However, thesegments can be connected by heterogeneous connection types, multipleconnection types (e.g., wired and wireless), or by any other suitableset of connections. The segments do not necessarily correspond tobroadcast or collision domains. For example, the entire network (e.g.,including multiple segments, such as two wireless mesh segments bridgedby an Ethernet segment) can define a single broadcast domain (oralternatively, can include multiple broadcast domains, such as VLANsdefined independent of the segments), and a single segment can includemultiple collision domains (and/or collision domains can extend intomultiple segments).

Each segment preferably includes all devices reachable by links ofsimilar type (e.g., reachable using only wireless links or only Ethernetlinks). However, the segments can alternatively exclude some suchdevices. In one example, segment definition can include a link qualitythreshold, wherein links below a threshold quality (e.g., threshold linkmetric value, such as a Bifrost metric value) are not ignored (e.g.,devices connected only by such a link would not be considered to be inthe same segment). In a second example, wireless segments can excludewireless links between nodes that are also connected by Ethernet (e.g.,wherein the wireless segment is limited to devices that must communicatewith each other wirelessly, rather than including all devices that cancommunicate with each other wirelessly). In a variation of this example,the method includes assessing (e.g., determining a link metric for) theEthernet links between such nodes, wherein the associated wireless linkis only excluded if the Ethernet link metric is better than a threshold(e.g., better than the wireless link metric, better than a predefinedthreshold, etc.). In a third example, each segment can be arbitrarilydivided into sub-segments. For example, a segment can be divided into anumber of sub-segments equal to the number of potential forwardingdevices in the segment, wherein each potential forwarding device isdesignated as the forwarding device for a different sub-segment.However, the segments can additionally or alternatively be defined inany other suitable manner.

Determining the segments preferably includes identifying each Ethernetsegment and each wireless segment. However, determining the segments canadditionally or alternatively include identifying only Ethernetsegments, identifying only wireless segments, identifying only a subsetof such segments, and/or determining any other suitable segments.Determining the segments can optionally include determining the members(e.g., connected devices) of some or all of the identified segments. Thesegments are preferably determined by the mesh nodes, such as bySTAMP-capable nodes that are both in a mesh segment and in an Ethernetsegment (e.g., nodes that connect a mesh segment to an Ethernetsegment). Preferably, the network does not include any mesh nodes thatalso have Ethernet connections but are not STAMP-capable, butalternatively the network can include any suitable nodes.

One embodiment of STAMP uses the IEEE 802.1d Spanning Tree Protocol tomap the Ethernet segments (e.g., wired Ethernet segments) attached toeach node, making their topologies acyclic in the ordinary manner (e.g.,the manner specified by STP). STP determines a unique “root bridgeaddress” for each contiguous Ethernet segment. Another embodiment ofSTAMP propagates other messages (e.g., in addition to or in place of STPmessages) in order to identify the Ethernet segments and/or theirmembers. The STAMP-capable nodes are preferably configured not to sendSTP messages and/or any other Ethernet segment mapping messages into themesh segments. Thus, such messages will propagate only within a singleEthernet segment (e.g., will not propagate through the wireless mesh),enabling the technique to distinguish between two non-contiguousEthernet segments.

However, mesh networks do not have an equivalent of a root node addressthat can be used to identify them. Instead, contiguity of mesh networksmay be determined by having each STAMP-capable node (or a subsetthereof, such as each node connected both to an Ethernet segment and awireless segment) send a broadcast message (the “STAMP announcement”)into the wireless segment to which it is connected. The STAMPannouncement preferably includes the identifier (e.g., as describedabove) of the wired Ethernet segment the sending node is connected to,as well as an identifier associated with the sending node (e.g., sendingnode MAC address). These broadcast messages are preferably tagged with aspecial ethertype, and STAMP-capable nodes are preferably configured todrop messages with the special ethertype at the mesh boundary (e.g.,configured not to forward them to Ethernet segments); that is, it doesnot propagate outside of the wireless mesh.

STAMP-capable nodes receive these STAMP announcement messages and builda list of every Ethernet segment visible from their mesh, wherein eachEthernet segment is associated with an identifier (e.g., the root bridgeaddress, the highest or lowest MAC address of the Ethernet devices inthe segment, etc.), and determine from the identifiers (e.g., theannounced root bridge addresses) which mesh nodes are members of thesame Ethernet segments.

The STAMP announcements can optionally include one or more STAMPmetrics, such as metrics associated with the sending node. These metricspreferably include a network segment centrality and/or connectivitymetric (e.g., representing how good the node's connection to the rest ofthe mesh segment is). In one variation, the STAMP metric of a node isdetermined based on the peer links of the node (e.g., all wireless peerlinks within the mesh segment, all Ethernet peer links, all peer linksof any type, etc.), such as being equal to the sum of the bitrates ofthe peer links or equal to the number of peer links. In a secondvariation, the STAMP metric is determined based on one or more HWMPmetrics associated with the node, such as the metrics described aboveregarding the system 100 (e.g., Bifrost metrics, learned and/or tunedmetrics, etc.). For example, the STAMP metric of a node can be equal tothe average of the path metrics between the node and each other memberof the wireless segment (e.g., simple average, load-weighted average,etc.). However, the STAMP announcements can additionally oralternatively include any other suitable STAMP metrics.

The STAMP metric (or metrics) is preferably used in order to determine(e.g., elect) a forwarding device (e.g., “designated forwarder”) foreach adjacent wireless segment-Ethernet segment pair (e.g., each placethat a given mesh touches a given Ethernet segment), such as shown inFIG. 7D for the wireless segment A-Ethernet segment B segment pair.However, the forwarding device can be otherwise determined at anysuitable time (e.g., at a predetermined frequency). For example, foreach such segment pair, the method 200 can include determining each meshnode that belongs to (e.g., is connected to) both the given wirelesssegment and the given Ethernet segment (e.g., the set of potentialforwarding devices), and then, based on the STAMP metric associated witheach potential forwarding device, designating one as the forwardingdevice for that pair (e.g., the mesh node with the best STAMP metric).The designation is preferably determined independently at each mesh nodeof the wireless segment (e.g., using an identical algorithm based onidentical information), but can alternatively be determined by a singlenode or other device (e.g., wherein the determination is then sent tothe devices of the wireless segment, such as included in subsequentSTAMP announcements). The method can optionally include designating oneor more backup forwarding devices (e.g., in a ranked order, in a pool,etc.), preferably wherein the backup forwarding device can assume theforwarding device role if the designated forwarding device becomesunresponsive (e.g., due to device failure, network partition, etc.).

The designated forwarding device is preferably responsible for movingframes between the wireless and Ethernet segments (e.g., receivingframes from the wireless segment and transmitting them into the Ethernetsegment, receiving frames from the Ethernet segment and transmittingthem into the wireless segment, etc.). In one example, the designatedforwarding device is responsible for moving frames multicast framesand/or broadcast frames on the mesh onto the Ethernet segment, and formoving unicast frames from the mesh not already present on the Ethernetsegment onto the Ethernet segment. In order to determine whether a frameshould be copied in this way, it can be necessary to do a lookup to seeif its origin is already a member of the same Ethernet segment as thedesignated forwarder; if it is, then we can assume that it alreadyinjected it onto the Ethernet segment, and the designated forwarder canleave it alone. In another example, the designated forwarding device issolely responsible for all inter-segment transmissions between thesegments to which it is connected. However, the designated forwardingdevice can additionally or alternatively serve any other suitable role.

Flooded unicast frames are special, because there is no provision in theEthernet header for marking them as such. The bridge that floods themdoes, however, know that it is flooding them, so they can be locallymarked as flooded. This local marking is used by the mesh driver to markthe frames in the mesh header. Flooded unicast frames emerging from themesh are treated similarly to multicast frames, so they are not injectedinto the Ethernet by multiple mesh nodes and therefore will alwaysapproach any switches on the Ethernet segment from the same direction ifthey come from the same address.

In order to know that a frame is coming from a node that is a member ofthe same Ethernet segment, the node's bridge must be able to check theSTAMP lists against the mesh header, but by the time the bridge gets theframe the mesh header will have been stripped and discarded. In order toallow this check to take place, a second local marking scheme is used,and a call from the mesh driver into the bridge is used in order tocheck the list.

In this way, flooded unicast frames can be checked as if they weremulticast frames, eliminating the chance of looping, and both unicastand multicast frames from the mesh will be delivered to all wiredEthernet segments in a predictable, deterministic way, avoiding thepossibility of confusing switches on those segments. This allows wiredEthernets to be connected to meshes, between mesh segments, and evenallows wired Ethernet bridges to be used between non-contiguous mesheswithout causing problems.

Other potential forwarding devices (e.g., those not designated as theforwarding device) associated with the segment pair preferably do notperform inter-segment forwarding for which the designated forwardingdevice is responsible. However, the potential forwarding devices canoperate in any suitable manner. In one example, each such node can actas though it is two separate devices—one connected to the wirelesssegment and the other to the Ethernet segment—with no direct data linkbetween them. In this example, transmissions received from the Ethernetsegment will only be forwarded by the node within the Ethernet segment(e.g., to Ethernet devices connected to the node by Ethernet), andtransmissions received from the wireless segment will only be forwardedby the node within the wireless segment (e.g., to wireless devicesconnected to the node by wireless links). In a second example, the nodecan determine a private sub-segment of devices that are connected to therest of a segment only by the node and that does not include adesignated forwarding device (or, in stricter versions, including onlydevices that are connected to the rest of the network only by the node,or including only client devices connected directly to the node and tono other devices), wherein the node is a “chokepoint” between thesub-segment and the rest of the network, and can perform inter-segmentforwarding only for the private sub-segment. For example, in this secondexample, in response to receiving a broadcast frame from the Ethernetsegment, the node can forward the broadcast frame to its privatesub-segment of the wireless segment (preferably recording that thebroadcast frame was received and forwarded to the private sub-segmentonly). When the node subsequently receives the same broadcast frame fromthe wireless segment (e.g., after forwarding into the wireless segmentby the designated forwarding device), it preferably does not forward itto the private sub-segment, thereby preventing the devices of theprivate sub-segment from receiving the frame more than once.

Path selections (e.g., as described above regarding the method 200, suchas regarding S230) between endpoints in different segments arepreferably determined based on the forwarding device designations. Inone variation, the method 200 only includes considering (e.g.,determining path metrics for) STAMP-compliant paths (e.g., paths thatrespect the forwarding device designations, such as paths that crossbetween a first and second segment only at the associated forwardingdevice). In a second variation, other paths may also be considered, butonly a STAMP-compliant path will be selected. In a specific example ofthis variation, if a non-compliant path metric is superior (e.g., by anyamount, by greater than a threshold amount, etc.) to a STAMP-compliantpath, the method can optionally include taking action that may changethe STAMP designations, such as providing updated information for STAMPmetric calculation, suggesting a STAMP metric adjustment (e.g., handicapbased on the contrast in path metrics), and/or requestingre-determination of the forwarding device. In a third variation, thepath metric (e.g., Bifrost metric) includes STAMP-related information(e.g., wherein non-compliance with the STAMP designations can penalize alink and/or path metric), but a non-compliant path may be selected.However, the STAMP designations can additionally or alternatively beintegrated with the path selection process in any other suitable manner,or can alternatively not be integrated.

As shown in FIG. 7A, non-contiguous networks of mixed Ethernet and meshare possible with STAMP. In FIG. 7A, the clouds represent mesh networksand cylinders represent client devices. STAMP nodes are represented byrounded rectangles and a legacy Ethernet switch is shown as a rectangle.The dotted lines represent 802.11 wireless links and the solid linesrepresent wired Ethernet connectivity.

Node A is the gateway node, connected to both the internet and the localnetwork; it is meshed with nodes B and C. All the Ethernet links in thenetwork comprised by nodes B, C and D are part of the same spanning treedomain. If an additional Ethernet link were added between nodes C and D,the STP process would disable one of the ports in order to preventloops.

Node D is not in radio contact with nodes A, B or C, so it creates itsown mesh network. It announces that it is a member of the Ethernetnetwork comprised by B, C and D on this small mesh, and since it is theonly member of this mesh, it becomes designated forwarder for trafficfrom this mesh to its Ethernet segment.

Meanwhile, on the mesh of which nodes A, B and C are members, node Aannounces that it has an Ethernet segment of its own, and since it isthe only member of that mesh which can contact that Ethernet segment, itis elected designated forwarder for that mesh—Ethernet boundary. Nodes Band C both have connectivity to their Ethernet segment, and are bothmembers of the same mesh, so they announce this fact. Whichever node hasthe best peer links to the mesh is elected designated forwarder. For thesake of this example, imagine that node B has better links and istherefore elected.

Upon receiving a STAMP notice of topology change, nodes announce the newinformation on the usual schedule. Each node starts announcing the newinformation as soon as it's found, and since the STAMP tables built byeach member of the mesh are indexed by a unique identifier (e.g., aSTAMP identifier, such as the bridge MAC address), the new informationreplaces the old within a few seconds. Stale information is handled bythe simple expedient of expiring it after a few update periods. Nodesnever announce information on behalf of other nodes, so there is noproblem of stale data being propagated.

If client 2 sends a broadcast frame, node D receives it and forwards itto its mesh, the other client of its access point (3) and the Ethernetsegment. Nodes B and C both receive it, as does client 1. Node Creceives it and would send it to any of its clients, had it any, but asit is not designated forwarder for its mesh, it does not forward it;node B does, and node A receives the frame from the mesh. Node Aforwards it to its own Ethernet segment, which does not have any clientsin any case.

In this way, the switch between nodes B and C always receives trafficfrom the same source along the same vector, and therefore does notmislearn the source's location.

Things are only slightly more complex if a client of node C sends abroadcast frame. In this case, even though node C is not the designatedforwarder, it injects the frame both into the Ethernet segment and themesh; upon receiving this frame via the mesh, node B notes that thesender of this frame (node C) is a member of the same Ethernet segment,since the frame on the mesh has been marked that way already, andtherefore it does not need to re-inject it into the Ethernet. Node Dsees the frame only via the Ethernet, and it knows that node C is not amember of its mesh, and it is the designated forwarder for thismesh-Ethernet interface, so it forwards it as appropriate.

It can be seen that because this protocol only requires nodes to knowabout the Ethernet segment they are a member of, and the mesh segmentthey are a member of, it can be scaled without limit, and will notpresent a problem for very large networks. Because it guarantees thatframes are delivered to wired Ethernet along the same vector every time,it does not require modifications to legacy Ethernet systems in order towork properly in connection with mesh networks. This is very differentfrom protocols which guarantee determinism by forcing centralconfiguration decisions to be made. In those systems, some central pointmust make decisions that affect the entire network, and there must be ascheme for communicating that information to every node in the network.

In keeping with the intrinsically decentralized, indefinitely scalablenature of mesh networks, STAMP achieves a similar level of performancewithout requiring any central authority or source of truth. As aconsequence, disruptions caused by the failure of any particular node tocorrectly apply the protocol are limited in scope; even incorrectlyinjected frames will only affect a single Ethernet segment. As long asthe nodes at the edges of a region are correctly applying STAMPmarkings, any looping or stochastic delivery will be localized to theregion served by the noncompliant node. This makes the network resilientto failures of communication between STAMP nodes.

The STAMP protocol (and/or any suitable elements thereof) can beperformed once, repeatedly (e.g., periodically, sporadically, inresponse to trigger occurrence, etc.), and/or with any other suitabletiming. For example, STAMP announcements can be broadcast (e.g.,periodically, such as every 15 seconds; in response to determination ofSTAMP metric and/or segment updates; etc.), and new forwarding devicescan be determined based on the announcements (e.g., periodically, suchas determined at the same periodic rate; in response to receipt of theSTAMP announcements; etc.).

The STAMP protocol or modifications described herein may be applied toan entire LAN; a VLAN (e.g., independently applied to each VLAN of anetwork), a set of VLANs, and/or any other suitable broadcast domain(s);a larger network (e.g., WAN, MAN, network including multiple LANs,etc.); and/or any other suitable networked system.

A person of ordinary skill in the art will recognize that the STAMPprotocol or modifications described herein may be applied to either ofthe system 100 or the method 200.

The methods of the preferred embodiment and variations thereof can beembodied and/or implemented at least in part as a machine configured toreceive a computer-readable medium storing computer-readableinstructions. The instructions are preferably executed bycomputer-executable components preferably integrated with a meshnetwork. The computer-readable medium can be stored on any suitablecomputer-readable media such as RAMs, ROMs, flash memory, EEPROMs,optical devices (CD or DVD), hard drives, floppy drives, or any suitabledevice. The computer-executable component is preferably a general orapplication specific processor, but any suitable dedicated hardware orhardware/firmware combination device can alternatively or additionallyexecute the instructions.

The FIGURES illustrate the architecture, functionality and operation ofpossible implementations of systems, methods and computer programproducts according to preferred embodiments, example configurations, andvariations thereof. In this regard, each block in the flowchart or blockdiagrams may represent a module, segment, step, or portion of code,which comprises one or more executable instructions for implementing thespecified logical function(s). It should also be noted that, in somealternative implementations, the functions noted in the block can occurout of the order noted in the FIGURES. For example, two blocks shown insuccession may, in fact, be executed substantially concurrently, or theblocks may sometimes be executed in the reverse order, depending uponthe functionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts, or combinations of special purpose hardware andcomputer instructions.

As a person skilled in the art will recognize from the previous detaileddescription and from the figures and claims, modifications and changescan be made to the preferred embodiments of the invention withoutdeparting from the scope of this invention defined in the followingclaims.

We claim:
 1. A method for network device communication, the methodcomprising: in a network comprising a wireless mesh segment and anEthernet segment, designating a first node as a forwarding device forcommunication between the wireless segment and the Ethernet segment,wherein: the wireless mesh segment comprises a plurality of wirelessdevices connected by wireless links, the plurality of wireless devicescomprising the first node and a second node; and the Ethernet segmentcomprises a plurality of Ethernet devices connected by Ethernet, theplurality of Ethernet devices comprising the first node and the secondnode; based on designating the first node as the forwarding device,determining a plurality of paths from a first device of the network to asecond device of the network, each path of the plurality of pathscomprising: the first node; and a respective set of wireless linksconnecting wireless devices of the path; determining, for each path ofthe plurality of paths, a respective path cost of the path, comprising,for each wireless link of the path, determining a respective link costbased on a throughput metric and a wireless channel utilization metric,wherein the respective path cost is equal to a sum of the respectivelink cost of each wireless link of the path; based on the path costs,selecting a selected path from the plurality of paths for communicationfrom the first device to the second device, wherein the selected pathhas a lowest respective path cost of the plurality of paths; and basedon selecting the selected path, transmitting a communication from thefirst device to the second device via the selected path; wherein, foreach wireless link of each path of the plurality of paths, determiningthe respective link cost of the wireless link comprises calculating arespective metric M associated with a node of the wireless link, whereinM is defined by the following equation:$M = \frac{C}{D\left( {1 - \frac{T_{busy} - T_{self}}{T_{active}}} \right)}$wherein C is a constant; D is the throughput metric associated with thenode; T_(active) is an active time during which the node is active on awireless channel associated with the wireless link; T_(busy) is a totalutilization time, within the active time, during which the wirelesschannel is in use; and T_(self) is a self-utilization time, within theactive time, during which the node is transmitting on the wirelesschannel.
 2. The method of claim 1, wherein the throughput metricassociated with the node is an exponentially weighted moving average ofa physical layer transmission throughput of the node.
 3. The method ofclaim 1, wherein: the wireless mesh segment comprises the first device;the Ethernet segment comprises the second device; and each path of theplurality of paths further comprises: a wireless link from a wirelessdevice of the wireless mesh segment to the first node; and an Ethernetlink from the first node to an Ethernet device of the Ethernet segment.4. The method of claim 1, wherein the wireless mesh segment comprisesthe first device; the Ethernet segment comprises the second device; andeach path of the plurality of paths further comprises: a first wirelesslink from a wireless device of the wireless mesh segment to the secondnode; a second wireless link from the second node to the first node; andan Ethernet link from the first node to an Ethernet device of theEthernet segment.
 5. The method of claim 1, wherein: a path cost of analternate path from the first device to the second device is lower thanthe path cost of the selected path; the alternate path comprises thesecond node; and the alternate path does not comprise the first node. 6.The method of claim 1, wherein: the wireless mesh segment consistsessentially of the plurality of wireless devices and the wireless linksconnecting the plurality of wireless devices; and the Ethernet segmentconsists essentially of the plurality of the Ethernet devices and theEthernet links connecting the plurality of Ethernet devices.
 7. Themethod of claim 1, further comprising: determining a second plurality ofpaths from the second device to the first device, each path of thesecond plurality of paths comprising a respective series of nodes of theplurality of nodes; determining, for each path of the second pluralityof paths, a respective evaluation of the path based on the throughputmetric and the wireless channel utilization metric; based on theevaluations, selecting a selected reverse path from the second pluralityof paths for communication from the second device to the first device,wherein the selected path does not comprise a reverse path node of theselected reverse path; and based on selecting the selected path,transmitting a second communication from the second device to the firstdevice via the selected reverse path.
 8. The method of claim 7, wherein,based on designating the first node as the forwarding device, the secondplurality of paths is determined such that each path of the secondplurality of paths comprises the first node.
 9. A method for networkdevice communication, the method comprising, in a mesh networkcomprising a first device, a second device, and a plurality of nodes:determining a plurality of paths from the first device to the seconddevice, each path of the plurality of paths comprising a respectiveseries of nodes of the plurality of nodes; determining, for each path ofthe plurality of paths, a respective evaluation of the path based on athroughput metric and a wireless channel utilization metric; based onthe evaluations, selecting a selected path from the plurality of pathsfor communication from the first device to the second device; based onselecting the selected path, transmitting a communication from the firstdevice to the second device via the selected path; determining a secondplurality of paths from the second device to the first device, each pathof the second plurality of paths comprising a respective series of nodesof the plurality of nodes; determining, for each path of the secondplurality of paths, a respective evaluation of the path based on thethroughput metric and the wireless channel utilization metric; based onthe evaluations, selecting a selected reverse path from the secondplurality of paths for communication from the second device to the firstdevice, wherein the selected path does not comprise a reverse path nodeof the selected reverse path; and based on selecting the selected path,transmitting a second communication from the second device to the firstdevice via the selected reverse path.
 10. The method of claim 9,wherein: each path of the plurality of paths further comprises arespective set of wireless links connecting nodes of the respectiveplurality series of nodes; for each path of the plurality of paths,determining the respective evaluation of the path comprises: for eachwireless link of the path, determining a respective link cost based onthe throughput metric and the wireless channel utilization metric; anddetermining a respective path cost equal to a sum of the respective linkcost of each wireless link of the path; and the selected path has alowest respective path cost of the plurality of paths.
 11. The method ofclaim 10, wherein, for each wireless link of each path of the pluralityof paths, determining the respective link cost of the wireless linkcomprises calculating a respective metric M associated with a node ofthe wireless link, wherein M is defined by the following equation:$M = \frac{C}{D\left( {1 - \frac{T_{busy} - T_{self}}{T_{active}}} \right)}$wherein C is a constant; D is the throughput metric associated with thenode; T_(active) is an active time during which the node is active on awireless channel associated with the wireless link; T_(busy) is a totalutilization time, within the active time, during which the wirelesschannel is in use; and T_(self) is a self-utilization time, within theactive time, during which the node is transmitting on the wirelesschannel.
 12. The method of claim 11, wherein the throughput metricassociated with the node is an exponentially weighted moving average ofa physical layer transmission throughput of the node.
 13. The method ofclaim 11, wherein determining the respective link cost of the wirelesslink further comprises modifying the metric based on a thermalthrottling factor associated with the node.
 14. The method of claim 10,wherein each path of the plurality of paths consists essentially of thefirst device, the second device, the respective series of nodes, and therespective set of wireless links.
 15. The method of claim 10, wherein afirst wireless link of the selected path comprises a first wirelessconnection at a first radio frequency and a second wireless connectionat a second radio frequency different from the first radio frequency.16. The method of claim 10, wherein the selected path further comprisesan Ethernet link.
 17. The method of claim 10, wherein, for each path ofthe plurality of paths: each wireless link of the path comprises arespective origin node and a respective destination node; for eachwireless link of the path, the respective link cost is determined at therespective origin node; and determining a respective path costcomprises, at each respective origin node: receiving a cumulative costfrom the respective destination node; and modifying the cumulative costby adding the respective link cost to the cumulative cost.
 18. Themethod of claim 9, wherein the throughput metric is an exponentiallyweighted moving average of a physical layer transmission throughput. 19.The method of claim 9, wherein the wireless channel utilization metricis determined based on utilization of a wireless channel and thermalthrottling of a radio associated with the wireless channel.